The present invention generally pertains to programming tools provided to a software developer. More particularly, the present invention pertains to programming tools for addressing resources, in particular resources that are compliant with the Common Language Specification.
Programming within a managed code execution environment is known in the art. One known example of such an environment is the environment that includes the Common Language Runtime (CLR). Compilers and tools expose the runtime's functionality and enable a developer to write code that benefits from managed code execution. Code that is developed with a language compiler that targets the runtime is known as managed code. Managed code benefits from features such as cross-language integration, cross-language exception handling, enhanced security, versioning and deployment support, a simplified model for component interaction, and debugging and profiling services.
It is an understood theory that to fully interact with other objects regardless of the language they were implemented in, objects should expose to callers those features that are common to the languages with which they are to inter-operate. With this theory in mind, the Common Language Specification (CLS), which is a set of basic language features common across multiple applications, has been defined. Languages that target the CLR have generally agreed to support CLS features and follow the CLS rules directed to compilers. Compilers for languages that target the CLR have simplified CLS compliance by making CLS data types and features available for creating components. If a component uses only CLS features in the API that it exposes to other code (including derived classes), the component is essentially guaranteed to be accessible from any programming language that supports the CLS. Components that adhere to the CLS rules and use only the features included in the CLS are said to be CLS-compliant components.
Generally speaking, current development environments provide only a cursory-level of support for managing resources, in particular CLS-compliant resources, at design time. In order to insert a resource into code, a developer is commonly required to hard code a reference identifier (e.g., from memory). Alternatively, a developer copies a reference identifier from a reference file (e.g., requiring the developer to switch back and forth between the coding program and the reference file).
A reference identifier for a resource commonly comprises a key name and a string. Given the present level of support for resource management, there is a significant risk that a developer will incorrectly type a key name or string. While the process of consulting a reference file to obtain a key name or string will theoretically reduce errors, the extra effort is tedious and therefore arguably provides some incentive for the developer to guess at the correct values. Of course, the process of guessing is prone to error.
It is common that a bug originating in an inaccurately addressed resource does not produce a build-time error and is typically discoverable at runtime only. This means that while a product is under test, the code-path that actually exercises the incorrectly addressed resource generally must be hit. Recognizing all addressing errors can be difficult without code-invasive measures. Also, for address correction under these testing circumstances, the tester of the application typically is required to correctly interpret an addressing error, which is not always an easy or straightforward task.